去年我做的是處理會議紀錄的 Agent，今年做的是常駐 Agent，這兩件事的難點落在不同的地方。

會議 Agent 的問題是一次性的：語音轉文字、摘要、寄信，串通就結束。常駐 Agent 的問題要跑幾天才出現，換更強的模型之後依然存在。

我遇到的三個問題

這三個是我自己遇到、並記錄下來的

跨 session 狀態在重啟後遺失

重新啟動後，先前寫入的偏好遺失。Hermes 內建 MEMORY.md 與 USER.md 搭配 FTS5 索引，寫入是條件觸發的，條件成立時才寫進檔案。

模型本身無狀態，context window 載入什麼就只知道什麼。 要跨 session 保留資訊，得有一層機制做兩件事：

• 對話結束前把該留的內容寫出
• 下次啟動時再讀回來

這層機制位在模型之外。

身分認知隨注入內容改變

Discord 群組頻道中，訊息以 顯示名稱: 內容 的格式送進 context，模型把前綴解析成自身 identity，回覆時自稱發話者的名稱。

根本原因是 identity 完全由注入內容決定。SOUL.md 的身分宣告只在 system prompt 出現一次，經 context 壓縮後被移除，剩下唯一可判斷 identity 的線索就是訊息開頭那個名字。

操作超出授權範圍

agent 的執行權限上限由它持有的 API 金鑰決定。同一條寄信限制，寫在兩個位置的效果不同：

• 寫在 prompt 裡：遵守與否取決於模型，事後只能從輸出推測
• OAuth scope 只授予讀取範圍：協定層擋在請求送出之前

兩者的差異在於能否驗證

缺的是三項機制

換上參數量更大的模型，它依然是無狀態的，identity 依然由注入內容決定，手上依然是同一組全權限金鑰。

這類問題屬於 Harness Engineering 的範圍：

Agent  =  Model  +  Harness

Harness 指包覆在 Model 外層的執行框架，它決定三件事：

• 模型看得到什麼
• 模型被允許做什麼
• 輸出如何驗證

Mitchell Hashimoto 的定義是：每當發現 agent 犯了一個錯，就花時間工程化一個解法，讓它再也不會犯同一個錯。

Guo 等人 2026 年的調查（arXiv:2606.20683）把 agent 工程的演進整理成四個範式：

前三者是疊加關係，第四者動到模型訓練，範圍超出這 30 天

Harness 的六項職責與選型

同一份調查把執行 harness 分解成六項耦合的執行期職責：

Model 位在這六項之外，是可替換的推論端點。

這六項互相耦合。 行動介面越有表達力，需要的權限控制就越強，而保存下來的產物決定了哪些證據可供查核。

未來 30 天的旅程

第一階段接上 Model 這一端並確認可替換性。 換掉推論端點後，其餘職責維持原狀。

第二階段處理內部狀態。 context window 的容量固定，system prompt 與工具 schema 會先佔去一部分，掛越多 MCP 剩越少。這段要量出每一項的實際佔用，再決定什麼該進 context、什麼該寫入長期記憶、身分宣告放在哪一項底下才撐得過壓縮。

第三階段處理外部行為。 工具要能被呼叫，而且要能證明它確實被呼叫過，權限邊界落在協定層。排程觸發之後，agent 要自己回讀狀態確認結果符合預期。

三十天結束時，這個 agent 要能在無人值守下依排程執行任務、驗證自己的輸出，並在失效時留下可追溯的紀錄